A repackaged jar contains the application’s classes and dependencies in BOOT-INF/classes and BOOT-INF/lib respectively. Similarly, an executable war contains the application’s classes in WEB-INF/classes and dependencies in WEB-INF/lib and WEB-INF/lib-provided. For cases where a docker image needs to be built from the contents of a jar or war, it’s useful to be able to separate these directories further so that they can be written into distinct layers.

Layered archives use the same layout as a regular repackaged jar or war, but include an additional meta-data file that describes each layer.

By default, the following layers are defined:

dependencies for any dependency whose version does not contain SNAPSHOT.

spring-boot-loader for the loader classes.

snapshot-dependencies for any dependency whose version contains SNAPSHOT.

application for local module dependencies, application classes, and resources.

Module dependencies are identified by looking at all of the modules that are part of the current build. If a module dependency can only be resolved because it has been installed into Maven’s local cache and it is not part of the current build, it will be identified as regular dependency.

The layers order is important as it determines how likely previous layers can be cached when part of the application changes. The default order is dependencies, spring-boot-loader, snapshot-dependencies, application. Content that is least likely to change should be added first, followed by layers that are more likely to change.

The repackaged archive includes the layers.idx file by default. To disable this feature, you can do so in the following manner:

Depending on your application, you may want to tune how layers are created and add new ones. This can be done using a separate configuration file that should be registered as shown below:

The configuration file describes how an archive can be separated into layers, and the order of those layers. The following example shows how the default ordering described above can be defined explicitly:

The layers XML format is defined in three sections:

The block defines how the application classes and resources should be layered.

The block defines how dependencies should be layered.

The block defines the order that the layers should be written.

Nested blocks are used within and sections to claim content for a layer. The blocks are evaluated in the order that they are defined, from top to bottom. Any content not claimed by an earlier block remains available for subsequent blocks to consider.

The block claims content using nested and elements. The section uses Ant-style path matching for include/exclude expressions. The section uses group:artifact[:version] patterns. It also provides and elements that can be used to include or exclude local module dependencies.

If no is defined, then all content (not claimed by an earlier block) is considered.

If no is defined, then no exclusions are applied.

Looking at the example above, we can see that the first will claim all module dependencies for the application.layer. The next will claim all SNAPSHOT dependencies for the snapshot-dependencies layer. The final will claim anything left (in this case, any dependency that is not a SNAPSHOT) for the dependencies layer.

The block has similar rules. First claiming org/springframework/boot/loader/** content for the spring-boot-loader layer. Then claiming any remaining classes and resources for the application layer.